Security and Trust in Open Source Security Tokens

Passwords are the most common authentication mechanism for private as well as professional IT services such as social media, banking or enterprise infrastructure. Unfortunately, the use of passwords leads to many security issues. Weak passwords allow for guessing or dictionary attacks, password re-use may lead to credential stuffing where stolen passwords are used for other services of the same users.

This is why hardware security tokens are often used as a second authentication factor to increase the security. These tokens have been designed to prevent the described threats effectively by using strong cryptography and a securely stored key. Although the use of security tokens is generally helpful to improve authentication security, tokens could be manipulated at multiple points before they reach the end user. Starting from the actual token designs going into internationally distributed production, then to the supply chain and distribution to end users, there is significant additional attack surface for malicious manipulation.

In the paper Security and Trust in Open Source Security Tokens, we investigated the trustworthiness of security tokens. We specifically concentrate on security tokens which are marketed as open source and focus on hardware attacks in supply chain and evil maid scenarios. We perform a systematic analysis of the most important commercially available candidates. The trustworthiness of the security tokens was assessed according to a top-down methodology which we outline shortly in the following. We uncovered several vulnerabilities for which we were able to contribute effective software-based mitigation measures to the respective open source projects. All details can be found in the paper. The uncovered vulnerabilities in hardware indicated that respective microchips must only be used with caution when security is important for a product.

© Fraunhofer AISEC
Architectural Attacks

Architectural Attacks

We started with an evaluation of the device architecture and by identifying components which are used for the storage of secrets and authentication operations. Based on the preliminary analysis, we investigated whether the existing inter-chip and debug interfaces have any exploitable logical flaws or are prone to known vulnerabilities. Within this step we successfully compromised the Nitrokey FIDO U2F and the Nitrokey Pro 2 token security measures. The Librem Key from Purism is identical to the Nitrokey Pro 2 and as such it is by this attack affected as well. The attacks are explained in detail in chapter 5 and 6 of this paper.

Relevant CVEs:

  • Nitrokey FIDO U2F - CVE-2020-12061
  • ST Microelectronics STM32F1 - CVE-2020-8004

Side-Channel Attacks

If the previous attempts did not reveal any weaknesses, we focused on the cryptographic implementations that are used during the authentication operations. For that, we used pen-like EM measurement probes with coarse spatial resolution and oscilloscopes operating in a sub-GHz range. This side-channel analysis led to the successful recovery of the private keys for the micro-ecc library, which is used within the Solokeys Solo and the Nitrokey FIDO2 token, and the ARM CryptoCell hardware accelerator, which is contained in the nRF52840 microcontroller and which is part of the Google OpenSK and the Feitian OpenSK token. The details about the side-channel analysis and key recovery is explained in chapter 7.1 and 8.1.

Relevant CVEs:

  • micro-ecc - CVE-2020-27209
  • Nordic Semiconductor nRF52840 - CVE-2020-27211
© Fraunhofer AISEC
Side-Channel Attacks

© Fraunhofer AISEC
Fault Injection Attacks

Fault Injection Attacks

To further assess the security, we investigated the hardware security features of the included chips in more detail. In this step, we evaluated if included chips exhibit exploitable vulnerabilities with the help of side-channel analyses and fault injections. Due to the black box nature of the implemented security measures reverse engineering effort is needed. We were able to circumvent the read-out protection of the STM32L4 and the nRF52840 microcontroller, which are used in the SoloKeys Solo & Somu, the Nitrokey FIDO2, the Google OpenSK and the Feititan OpenSK. The details of these attacks can be found in chapter 7.2 and 8.2.

Relevant CVEs:

  • ST Microelectronics STM32L4 - CVE-2020-27212, CVE-2021-29414
  • Nordic Semiconductor nRF52840 - CVE-2021-29415
  • SoloKeys Solo & Somu - CVE-2020-27208
  • Nitrokey FIDO2 - CVE-2020-27208

Despite our findings, authentication tokens and second factor authentication are clearly beneficial for security. However, our findings show that it is not always easy to rely on hardware security features which are provided by chip manufacturers. We conclude that it is highly important to carefully assess the security of microchips against physical attacks in a capable laboratory. Some vulnerabilities can be mitigated using proper countermeasures, as it was the case here. We proposed effective countermeasures which, at the time of writing, have already been partially implemented. In this way we were able to contribute to the security of current and future authentication tokens. In other cases, however, hardware vulnerabilities may be unrecoverable. This shows the high relevance of hardware security for the security of end products. The full details of the analysis, attacks as well as countermeasures can be found in the paper, which is open access and linked below.

Authors

Contact Press / Media

Marc Schink

Hardware Security

Fraunhofer AISEC
Lichtenbergstraße 11
85748 Garching b. München

Telefon  +49 89 3229986-144

Contact Press / Media

Alexander Wagner

Hardware Security

Fraunhofer AISEC
Lichtenbergstraße 11
85748 Garching b. München

Telefon  +49 89 3229986-149

Contact Press / Media

Florian Unterstein

Hardware Security

Fraunhofer AISEC
Lichtenbergstraße 11
85748 Garching b. München